On 06/09/2015 07:50 PM, Lennart Poettering wrote:
On Tue, 09.06.15 11:30, Jóhann B. Guðmundsson ([email protected]) wrote:
I would like to see us move and migrated the bugs to jira ( which is without
doubt the best and friendliest bug tracker I have found ) which integrates
nicely with github as well as move the community wiki to confluence to
strengthen collaboration in the community.
Well, I already feel uncomfortable with moving things to one closed
source platform in github, but given the advantages I accept
it. However, moving things to *two* closed source platforms sounds
even worse to me. If we bind our project to closed source companies I
much prefer sticking to one, instead of two.
There is no difference between one or many "closed source" since you
decided to head down this road et all and I have yet to see the problem
you sought out to alleviate will be solved with that change or that
change alone for that matter.
Personally I'm not foreseeing us ever hacking on Atlassian source code
directly but rather extend it via plugins ( locally written or otherwise
) if the need arise ( which afaik would be only needed for QA related
stuff ) so I dont see how you really can call this "closed source"
however the source code for Atlassian products is available to license
holders and they offer free licenses for official open source projects
[¹] which covers all the plugins on the market place as well.
Also, while I see quite a few shortcomings in github model, pure bug
tracking certainly isn't where the shortcomings are, it's more about
tracking patches where I am not convinced, but I doubt JIRA will fix
that part for us... or will it?
I beg the differ for pure bug tracking it is quite limited.
The fact is we are long overdue building a proper infrastructure to
sustain the building block of modern OS.
We need to do proper QA to properly support and backup our downstream
consumers ( distributions, embedded and otherwise) and that means
tagging bugs by distributions, vendors, releases.
Once bug has been validated, write test cases to prevent them from
happening again. provide them with prebuild packages to test ( and or
only provide it as btrfs snapshots to avoid having to deal with plethora
of packaging formats ) write proper release notes, provide proper
documentation etc. means to correctly identify and allocate resources as
needed.
The better work we do here is, the less is the work downstream consumers
have do to downstream.
I would be the one that would overseeing and handling the migration and I
was hoping David Strauss might be willing to host that infrastructure for us
and or some other place for that matter ( mini pc in systemd's HQ in German
maybe ?)
I am very much of the opinion that we should be very careful when
commiting to maintain our own infrastructure. You know how
undermaintained fdo was, and if we do it on our own it's even
worse. Administrating our own servers is a huge amount of work
especially given you have to do this over a long long time
continously, and our workforce is already too limited for the amount
of work we have to do.
This is not as high maintenance as you let it out to be or resource
intensive for that matter. ( I design this with mini pc in mind, intel
nuc and the like so this could be hosted here at home if necessary and
or relocated to Germany if requested )
The infrastructure for this is well maintainable by a single individual
in his spare time however four ( or more ) individuals providing their
free time would be optimal.
Your workforce is limited to what you make it out to be and you seemed
to be fixating on development resources alone which arguably is wrong on
two accounts.
First development resource are small ( but important ) part of a
successful project.
Secondly the success to systemd is thanks to collaborated effort between
individuals residing in downstream consumer community's and this is
where that collaboration effort would continue to grow since this is
where the contributed time is best spent ( and least time I checked the
community was far greater then what ca 20 committed developers )
That said I was designing my work to reduce work on direct development
resources not increase it ( which infrastructure resources are supposed
to do ) so if you have to spent 10 minutes more once implemented than
you did before this effort will have become a failure..
One of the major benefits of github I think is that it's their very
business to administer the site for us, and they'll do it as well as
they possibly can. That gets substantially more difficult if we roll
that all on our own, given that most of us have little desire to
become administrators oursevles and we have no budget for paying one
over years.
I had already taken money issue into account ( and even built a project
within jira to handle that process ) since I did not expect nor want Red
Hat to fund this effort.
( The solution to this problem needs to arise from within the community
to become self sustainable and accepted by all invested parties, there
is far to red label associated with our collaborated effort )
There are several ways to fund communities, we could offer consultation,
migration, integration and or forward that work to third party for % of
the fee he charges and or "sponsor ship ( EU, companies etc
)",indigo/kickstart campaign ( that helped the Gnome community ) etc.
Btw this is not a replacement to github but addon hence worst case
scenario we just end up using github just as we started out with.
JBG
1. offer free licenses for official Open Source Projects and community
organizations
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
