Fedora hosted planning

[Kevin Fenzi]

Greetings. 

So, looking at fedorahosted, I thought I would start some discussion
about where we are and where we need to go short and longer term. 

Right now hosted03/04 are rhel6 and still in puppet. Short term, I
would very much like to move them to ansible, and ideally to rhel7. 

I looked into the trac situation upstream. We are currently using
0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6 thats
out, but it looks like that might be the last release in the 0.12
series (or there might be a 0.12.7, but thats likely to be it). They
are looking at doing releases yearly if they can manage, so 1.2 would
appear later this year, then 1.3, etc. It's not clear how long 1.0 will
be supported really. At least a year, but not clear after that. 

So, as I see it, our options are: 

1 Just move to ansible, leave on rhel6 for now until we decide
  something better. 

2 Move to ansible and rhel7, and build out trac-1.0 and plugins in
  epel7. This will take a bit longer since there's so many plugins, but
  shouldn't really be that hard. 

3 Move to ansible and rhel7 and progit. I'm not sure if progit is ready
  to replace trac though. I think it might need wiki features and also
  more ticket handling stuff, since some of our projects use trac
  ticketing heavily. 

4 a combo of 2 and 3 (ie, offer trac and progit both)

5. a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
move ones that want to progit, eventually we have a flag day and move
the rest). 

6. Some other brilliant plan. ;) 

Thoughts? ideas? will also add this to the gobby doc to discuss in
meeting. 

kevin

[Stephen John Smoogen]

On 3 March 2015 at 13:22, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  Greetings.
>
>  So, looking at fedorahosted, I thought I would start some discussion
>  about where we are and where we need to go short and longer term.
>
>  Right now hosted03/04 are rhel6 and still in puppet. Short term, I
>  would very much like to move them to ansible, and ideally to rhel7.
>
>  I looked into the trac situation upstream. We are currently using
>  0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6 thats
>  out, but it looks like that might be the last release in the 0.12
>  series (or there might be a 0.12.7, but thats likely to be it). They
>  are looking at doing releases yearly if they can manage, so 1.2 would
>  appear later this year, then 1.3, etc. It's not clear how long 1.0 will
>  be supported really. At least a year, but not clear after that.
>
>  So, as I see it, our options are:
>
>  1 Just move to ansible, leave on rhel6 for now until we decide
>    something better.
>
>  2 Move to ansible and rhel7, and build out trac-1.0 and plugins in
>    epel7. This will take a bit longer since there's so many plugins, but
>    shouldn't really be that hard.
>
>  3 Move to ansible and rhel7 and progit. I'm not sure if progit is ready
>    to replace trac though. I think it might need wiki features and also
>    more ticket handling stuff, since some of our projects use trac
>    ticketing heavily.
>
>  4 a combo of 2 and 3 (ie, offer trac and progit both)
>
>  5. a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
>  move ones that want to progit, eventually we have a flag day and move
>  the rest).
>
>  
5 sounds like the most likely. There are a lot of work flows which groups
are using with the current trac. If they didn't.. they would have probably
moved over to github by now. Having the old boxes on ansible is probably
faster by at least 18 months over getting people moved to the newer system.




>  6. Some other brilliant plan. ;)
>
>  Thoughts? ideas? will also add this to the gobby doc to discuss in
>  meeting.
>
>  kevin
>
>  _______________________________________________
>  infrastructure mailing list
>  infrastructure(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>  


-- 
Stephen J Smoogen.

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 3 Mar 2015 13:30:26 -0700
Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:

>  On 3 March 2015 at 13:22, Kevin Fenzi <kevin(a)scrye.com&gt;
> wrote:
>  
>  > Greetings.
>  >
>  > So, looking at fedorahosted, I thought I would start some discussion
>  > about where we are and where we need to go short and longer term.
>  >
>  > Right now hosted03/04 are rhel6 and still in puppet. Short term, I
>  > would very much like to move them to ansible, and ideally to rhel7.
>  >
>  > I looked into the trac situation upstream. We are currently using
>  > 0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6
>  > thats out, but it looks like that might be the last release in the
>  > 0.12 series (or there might be a 0.12.7, but thats likely to be
>  > it). They are looking at doing releases yearly if they can manage,
>  > so 1.2 would appear later this year, then 1.3, etc. It's not clear
>  > how long 1.0 will be supported really. At least a year, but not
>  > clear after that.
>  >
>  > So, as I see it, our options are:
>  >
>  > 1 Just move to ansible, leave on rhel6 for now until we decide
>  >   something better.
>  >
>  > 2 Move to ansible and rhel7, and build out trac-1.0 and plugins in
>  >   epel7. This will take a bit longer since there's so many plugins,
>  > but shouldn't really be that hard.
>  >
>  > 3 Move to ansible and rhel7 and progit. I'm not sure if progit is
>  > ready to replace trac though. I think it might need wiki features
>  > and also more ticket handling stuff, since some of our projects use
>  > trac ticketing heavily.
>  >
>  > 4 a combo of 2 and 3 (ie, offer trac and progit both)
>  >
>  > 5. a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
>  > move ones that want to progit, eventually we have a flag day and
>  > move the rest).
>  >
>  >
>  5 sounds like the most likely. There are a lot of work flows which
>  groups are using with the current trac. If they didn't.. they would
>  have probably moved over to github by now. Having the old boxes on
>  ansible is probably faster by at least 18 months over getting people
>  moved to the newer system.
>  
I refuse to use github because I personally think its very bad for us as
a open and transparent community and project that prides itself on
making sure everyone can mimic what we do exactly to use something
closed and proprietary. For my own projects I think I would mostly be
okay with progit though something would be needed for ticketing for
releng, wiki space would be good for some projects but is not really
needed on all projects. some like mash only have a git repo on
fedorahosted, there is no associated trac. I think 4 or 5 would both be
viable.

Dennis
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBAgAGBQJU9odlAAoJEH7ltONmPFDRN18QAMBcPSKO86ov03u8uSM+x/xL
> rix7Zsjqq9aKz0uqoq2RTqUa1HmHv/L5imO2yl3iOBr25q6yI7NQPNn8NRvBScjt
> OIix26GxosS7sPkmzqioEVklOPFfoYmdy4lK1ZLZKuJ0AGRJ/8piUBGOyrKb1OIY
> 215uzX/CcO4R8qFAgqpe2gVYIGxY+oJribbYn3c7r/ejeczvPcgDLDjBugNyrT5J
> oj1zxDNVcYq9CZN12Lu2N6KeSjI8C175OhsY/LCyt7aZggpTn9PsYWsJ9p341tHS
> PzLOREB8pJ28loH7IaqmHTW17TsNMO5ru8UCyXYurBBURTDo/PEB6LyueObMJQqj
> r0CYPz8wuBFsUBByxSMiDSDZCQDMHrh4MHUnHYDAYDnezACqnnc9DayN1eVxmc5r
> ogUPzGXq+hKCLxUr/EbAefC5t75D4AATdVYBJFeOEDDnF9PUdFJuIx+7mtPnWeCW
> s1b8ZK+rt4sKHV0u4oa0GESa7/e/kn3gkqmZo/uByjvqsu9taCu09I5Yzhn8fznt
> FR5MfiNtXFsBHZW5zE7jQHA0bc8gaavuGKJiiztV96E0aQR97hQsD22o1DuNjTTU
> yk34dulI/4U7WmBsK1qA3vq05SDea6Ix8awbU3T3JEtVz7lIsiODGZBGOu04BDVT
> 3/y/imYhhXW9fAvZteUl
> =UTPw
> -----END PGP SIGNATURE-----
>

[Ralph Bean]

On Tue, Mar 03, 2015 at 01:30:26PM -0700, Stephen John Smoogen wrote:
>  On 3 March 2015 at 13:22, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  
>  > Greetings.
>  >
>  > So, looking at fedorahosted, I thought I would start some discussion
>  > about where we are and where we need to go short and longer term.
>  >
>  > Right now hosted03/04 are rhel6 and still in puppet. Short term, I
>  > would very much like to move them to ansible, and ideally to rhel7.
>  >
>  > I looked into the trac situation upstream. We are currently using
>  > 0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6 thats
>  > out, but it looks like that might be the last release in the 0.12
>  > series (or there might be a 0.12.7, but thats likely to be it). They
>  > are looking at doing releases yearly if they can manage, so 1.2 would
>  > appear later this year, then 1.3, etc. It's not clear how long 1.0 will
>  > be supported really. At least a year, but not clear after that.
>  >
>  > So, as I see it, our options are:
>  >
>  > 1 Just move to ansible, leave on rhel6 for now until we decide
>  >   something better.
>  >
>  > 2 Move to ansible and rhel7, and build out trac-1.0 and plugins in
>  >   epel7. This will take a bit longer since there's so many plugins, but
>  >   shouldn't really be that hard. 
I'd vote for 1 or 2 as things we can accomplish shorter-term.

>  >
>  > 3 Move to ansible and rhel7 and progit. I'm not sure if progit is ready
>  >   to replace trac though. I think it might need wiki features and also
>  >   more ticket handling stuff, since some of our projects use trac
>  >   ticketing heavily.
>  >
>  > 4 a combo of 2 and 3 (ie, offer trac and progit both)
>  >
>  > 5. a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
>  > move ones that want to progit, eventually we have a flag day and move
>  > the rest).
>  >
>  >
>  5 sounds like the most likely. There are a lot of work flows which groups
>  are using with the current trac. If they didn't.. they would have probably
>  moved over to github by now. Having the old boxes on ansible is probably
>  faster by at least 18 months over getting people moved to the newer system. 
I'm not sure progit is going to be ready to wholesale replace
fedorahosted anytime soon.  Perhaps we can 'promote' it though to get
more of an idea of where its at, say give it a domain name at
progit.cloud.fedoraproject.org ?  Let's get a few more people/projects
using it.

I'm not sure that adding wiki features and trying to get parity with
trac's ticketing system are going to be simple.  A barebones
implementation could be done, but there will be a long stream of
support/RFE tickets that follow if we head down that road.

[Pierre-Yves Chibon]

On Wed, Mar 04, 2015 at 11:12:30AM -0500, Ralph Bean wrote:
>  On Tue, Mar 03, 2015 at 01:30:26PM -0700, Stephen John Smoogen
> wrote:
>  > On 3 March 2015 at 13:22, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  > > So, as I see it, our options are:
>  > >
>  > > 1 Just move to ansible, leave on rhel6 for now until we decide
>  > >   something better.
>  > >
>  > > 2 Move to ansible and rhel7, and build out trac-1.0 and plugins in
>  > >   epel7. This will take a bit longer since there's so many plugins, but
>  > >   shouldn't really be that hard.
>  
>  I'd vote for 1 or 2 as things we can accomplish shorter-term. 
Depending on how is/hard it is, I'd vote for this as well (see below).

>  > >
>  > > 3 Move to ansible and rhel7 and progit. I'm not sure if progit is ready
>  > >   to replace trac though. I think it might need wiki features and also
>  > >   more ticket handling stuff, since some of our projects use trac
>  > >   ticketing heavily.
>  > >
>  > > 4 a combo of 2 and 3 (ie, offer trac and progit both)
>  > >
>  > > 5. a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
>  > > move ones that want to progit, eventually we have a flag day and move
>  > > the rest).
>  > >
>  > >
>  > 5 sounds like the most likely. There are a lot of work flows which groups
>  > are using with the current trac. If they didn't.. they would have probably
>  > moved over to github by now. Having the old boxes on ansible is probably
>  > faster by at least 18 months over getting people moved to the newer system.
>  
>  I'm not sure progit is going to be ready to wholesale replace
>  fedorahosted anytime soon.  Perhaps we can 'promote' it though to get
>  more of an idea of where its at, say give it a domain name at
>  progit.cloud.fedoraproject.org ?  Let's get a few more people/projects
>  using it. 
While I kinda hope progit gets to a state where it is used and useful, I do not
see our trac instances all moving away any time soon (thus the vote for 1
or/and 2).

Having progit.dev.fedoraproject and later maybe progit.fedoraproject.org would
already help (I'd rather have .dev. than .cloud. in the url as I believe it is
more indicative of the state of the application there).
I am planning on blogging and calling for testers once I got around fixing what
I still want to fix (unit-tests and finish the git integration for tickets, git
integration for pull-request is on the roadmap but I won't wait for it before
calling for testers). More people testing will likely also help finding out how
usable the system is.

>  I'm not sure that adding wiki features and trying to get parity
> with
>  trac's ticketing system are going to be simple.  A barebones
>  implementation could be done, but there will be a long stream of
>  support/RFE tickets that follow if we head down that road. 
Regarding progit, it will not grow a wiki feature but offers the possibility to
have a doc repo containing text, html, markdown or rest files (the last two will
be rendered, the first two display).

For the ticketing system, we currently have:
 Tags:
 Assigned:
 Blocking:
 Depends on:
 Status:
So there won't be a roadmap as there is in trac, but this can be implemented
using the Tags, issue dependency is in, as well as assigning issues.

Do we need something else?


Pierre

[Kevin Fenzi]

On Wed, 4 Mar 2015 23:09:03 +0100
Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:

>  While I kinda hope progit gets to a state where it is used and
>  useful, I do not see our trac instances all moving away any time soon
>  (thus the vote for 1 or/and 2). 
Fair enough. 

>  Having progit.dev.fedoraproject and later maybe
>  progit.fedoraproject.org would already help (I'd rather have .dev.
>  than .cloud. in the url as I believe it is more indicative of the
>  state of the application there). I am planning on blogging and
>  calling for testers once I got around fixing what I still want to fix
>  (unit-tests and finish the git integration for tickets, git
>  integration for pull-request is on the roadmap but I won't wait for
>  it before calling for testers). More people testing will likely also
>  help finding out how usable the system is. 
Also very reasonable. 

It might be good to settle on a new name first? That way there's 'buzz'
about it and you don't have to change it after people know it. 
 
>  Regarding progit, it will not grow a wiki feature but offers the
>  possibility to have a doc repo containing text, html, markdown or
>  rest files (the last two will be rendered, the first two display). 
I think that would actually meet the needs of the folks that are using
the trac wiki pretty nicely. 
 
>  For the ticketing system, we currently have:
>   Tags:
>   Assigned:
>   Blocking:
>   Depends on:
>   Status:
>  So there won't be a roadmap as there is in trac, but this can be
>  implemented using the Tags, issue dependency is in, as well as
>  assigning issues.
>  
>  Do we need something else? 
Possibly some way to have sensitive/private tickets?

There may be some small number of people using the roadmap feature (ie,
mark 10 tickets for a milestone, when they are solved the release
happens, etc)

Ability to mass modify tickets (so you could say "new release, please
retest your bug with this version")

libravatar support. 

Ability to 'watch' all tickets for a project, ie see all comments to a
list or list of addresses. 

Templates for some kinds of requests?

Way to attach to tickets? I guess tho that could be done by PR's really
most of the time. 

There may be other things, but those are the ones that leap to mind. 

kevin

[Ralph Bean]

On Wed, Mar 04, 2015 at 07:27:59PM -0700, Kevin Fenzi wrote:
>  There may be other things, but those are the ones that leap to mind. 
And publish fedmsg messages about activity... :)

[Pierre-Yves Chibon]

On Wed, Mar 04, 2015 at 07:27:59PM -0700, Kevin Fenzi wrote:
>  On Wed, 4 Mar 2015 23:09:03 +0100
>  Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:
>  > Having progit.dev.fedoraproject and later maybe
>  > progit.fedoraproject.org would already help (I'd rather have .dev.
>  > than .cloud. in the url as I believe it is more indicative of the
>  > state of the application there). I am planning on blogging and
>  > calling for testers once I got around fixing what I still want to fix
>  > (unit-tests and finish the git integration for tickets, git
>  > integration for pull-request is on the roadmap but I won't wait for
>  > it before calling for testers). More people testing will likely also
>  > help finding out how usable the system is.
>  
>  Also very reasonable. 
>  
>  It might be good to settle on a new name first? That way there's 'buzz'
>  about it and you don't have to change it after people know it.  
Yes, I clearly need to figure this out soon!

>  > Regarding progit, it will not grow a wiki feature but offers
> the
>  > possibility to have a doc repo containing text, html, markdown or
>  > rest files (the last two will be rendered, the first two display).
>  
>  I think that would actually meet the needs of the folks that are using
>  the trac wiki pretty nicely.  
Cool :)

>  > For the ticketing system, we currently have:
>  >  Tags:
>  >  Assigned:
>  >  Blocking:
>  >  Depends on:
>  >  Status:
>  > So there won't be a roadmap as there is in trac, but this can be
>  > implemented using the Tags, issue dependency is in, as well as
>  > assigning issues.
>  > 
>  > Do we need something else?
>  
>  Possibly some way to have sensitive/private tickets? 
http://209.132.184.222/progit/issue/49

>  There may be some small number of people using the roadmap feature
> (ie,
>  mark 10 tickets for a milestone, when they are solved the release
>  happens, etc) 
I think this can be achieved with tags:
http://209.132.184.222/progit/issues?tags=doc
list the ticket opened and with this tag

>  Ability to mass modify tickets (so you could say "new release,
> please
>  retest your bug with this version") 
I'd consider this be part of the API

>  libravatar support.  
Already there:
http://209.132.184.222/progit/blob/master/progit/__init__.py#_366
and
http://209.132.184.222/progit/blob/master/progit/lib/__init__.py#_831

>  Ability to 'watch' all tickets for a project, ie see all
> comments to a
>  list or list of addresses.  
http://209.132.184.222/progit/issue/50

>  Templates for some kinds of requests? 
Not sure about this but:
http://209.132.184.222/progit/issue/51

>  Way to attach to tickets? I guess tho that could be done by PR's
> really
>  most of the time.  
Oh yeah, definitely :)
http://209.132.184.222/progit/issue/52
This would also help to report problem with screenshot :)

As for Ralph:
http://209.132.184.222/progit/issue/53


Thanks all :)
Feel free to drop in any tickets you like to comment or patch things :)

Pierre

[Xavier Lamien]

On Tue, Mar 3, 2015 at 9:23 PM Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  1 Just move to ansible, leave on rhel6 for now until we decide
>    something better.
>
>  2 Move to ansible and rhel7, and build out trac-1.0 and plugins in
>    epel7. This will take a bit longer since there's so many plugins, but
>    shouldn't really be that hard.
>
>  
+1


>  3 Move to ansible and rhel7 and progit. I'm not sure if progit is
> ready
>    to replace trac though. I think it might need wiki features and also
>    more ticket handling stuff, since some of our projects use trac
>    ticketing heavily.
>  
We also have projects which don't use git as vcs.

[Paul W. Frields]

On Tue, Mar 03, 2015 at 10:17:41PM -0600, Dennis Gilmore wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  On Tue, 3 Mar 2015 13:30:26 -0700
>  Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  
>  > On 3 March 2015 at 13:22, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  > 
>  > > Greetings.
>  > >
>  > > So, looking at fedorahosted, I thought I would start some discussion
>  > > about where we are and where we need to go short and longer term.
>  > >
>  > > Right now hosted03/04 are rhel6 and still in puppet. Short term, I
>  > > would very much like to move them to ansible, and ideally to rhel7.
>  > >
>  > > I looked into the trac situation upstream. We are currently using
>  > > 0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6
>  > > thats out, but it looks like that might be the last release in the
>  > > 0.12 series (or there might be a 0.12.7, but thats likely to be
>  > > it). They are looking at doing releases yearly if they can manage,
>  > > so 1.2 would appear later this year, then 1.3, etc. It's not clear
>  > > how long 1.0 will be supported really. At least a year, but not
>  > > clear after that.
>  > >
>  > > So, as I see it, our options are:
>  > >
>  > > 1 Just move to ansible, leave on rhel6 for now until we decide
>  > >   something better.
>  > >
>  > > 2 Move to ansible and rhel7, and build out trac-1.0 and plugins in
>  > >   epel7. This will take a bit longer since there's so many plugins,
>  > > but shouldn't really be that hard.
>  > >
>  > > 3 Move to ansible and rhel7 and progit. I'm not sure if progit is
>  > > ready to replace trac though. I think it might need wiki features
>  > > and also more ticket handling stuff, since some of our projects use
>  > > trac ticketing heavily.
>  > >
>  > > 4 a combo of 2 and 3 (ie, offer trac and progit both)
>  > >
>  > > 5. a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
>  > > move ones that want to progit, eventually we have a flag day and
>  > > move the rest).
>  > >
>  > >
>  > 5 sounds like the most likely. There are a lot of work flows which
>  > groups are using with the current trac. If they didn't.. they would
>  > have probably moved over to github by now. Having the old boxes on
>  > ansible is probably faster by at least 18 months over getting people
>  > moved to the newer system.
>  
>  I refuse to use github because I personally think its very bad for us as
>  a open and transparent community and project that prides itself on
>  making sure everyone can mimic what we do exactly to use something
>  closed and proprietary. For my own projects I think I would mostly be
>  okay with progit though something would be needed for ticketing for
>  releng, wiki space would be good for some projects but is not really
>  needed on all projects. some like mash only have a git repo on
>  fedorahosted, there is no associated trac. I think 4 or 5 would both be
>  viable. 
[Sorry for catching up late to this thread.]

I'm not comfortable yet with the idea of taking on the service
build-out that (3) represents above.  That's a lot of commitment for
something I don't think we can call critical path.  Github may be a
closed/paid service solution but it doesn't affect the public
availability, transparency or forkability of any of our code.  And a
long-term investment in chasing that solution as a Fedora-specific
service to replace hosted is not necessarily the best use of our
resources.


-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com

[Dennis Gilmore]

On Tuesday, March 10, 2015 05:56:58 PM Paul W. Frields wrote:
>  On Tue, Mar 03, 2015 at 10:17:41PM -0600, Dennis Gilmore wrote:
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  > 
>  > On Tue, 3 Mar 2015 13:30:26 -0700
>  > 
>  > Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  > > On 3 March 2015 at 13:22, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  > > > Greetings.
>  > > > 
>  > > > So, looking at fedorahosted, I thought I would start some discussion
>  > > > about where we are and where we need to go short and longer term.
>  > > > 
>  > > > Right now hosted03/04 are rhel6 and still in puppet. Short term, I
>  > > > would very much like to move them to ansible, and ideally to rhel7.
>  > > > 
>  > > > I looked into the trac situation upstream. We are currently using
>  > > > 0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6
>  > > > thats out, but it looks like that might be the last release in the
>  > > > 0.12 series (or there might be a 0.12.7, but thats likely to be
>  > > > it). They are looking at doing releases yearly if they can manage,
>  > > > so 1.2 would appear later this year, then 1.3, etc. It's not clear
>  > > > how long 1.0 will be supported really. At least a year, but not
>  > > > clear after that.
>  > > > 
>  > > > So, as I see it, our options are:
>  > > > 
>  > > > 1 Just move to ansible, leave on rhel6 for now until we decide
>  > > > 
>  > > >   something better.
>  > > > 
>  > > > 2 Move to ansible and rhel7, and build out trac-1.0 and plugins in
>  > > > 
>  > > >   epel7. This will take a bit longer since there's so many plugins,
>  > > > 
>  > > > but shouldn't really be that hard.
>  > > > 
>  > > > 3 Move to ansible and rhel7 and progit. I'm not sure if progit is
>  > > > ready to replace trac though. I think it might need wiki features
>  > > > and also more ticket handling stuff, since some of our projects use
>  > > > trac ticketing heavily.
>  > > > 
>  > > > 4 a combo of 2 and 3 (ie, offer trac and progit both)
>  > > > 
>  > > > 5. a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
>  > > > move ones that want to progit, eventually we have a flag day and
>  > > > move the rest).
>  > > 
>  > > 5 sounds like the most likely. There are a lot of work flows which
>  > > groups are using with the current trac. If they didn't.. they would
>  > > have probably moved over to github by now. Having the old boxes on
>  > > ansible is probably faster by at least 18 months over getting people
>  > > moved to the newer system.
>  > 
>  > I refuse to use github because I personally think its very bad for us as
>  > a open and transparent community and project that prides itself on
>  > making sure everyone can mimic what we do exactly to use something
>  > closed and proprietary. For my own projects I think I would mostly be
>  > okay with progit though something would be needed for ticketing for
>  > releng, wiki space would be good for some projects but is not really
>  > needed on all projects. some like mash only have a git repo on
>  > fedorahosted, there is no associated trac. I think 4 or 5 would both be
>  > viable.
>  
>  [Sorry for catching up late to this thread.]
>  
>  I'm not comfortable yet with the idea of taking on the service
>  build-out that (3) represents above.  That's a lot of commitment for
>  something I don't think we can call critical path.  Github may be a
>  closed/paid service solution but it doesn't affect the public
>  availability, transparency or forkability of any of our code.  And a
>  long-term investment in chasing that solution as a Fedora-specific
>  service to replace hosted is not necessarily the best use of our
>  resources. 
We can agree to disagree here. I think without a good viable open source

option we will be locked into a closed proprietary platform. if github jacks 
up the price or closes down, yes we still have our clones and can put the data 
elsewhere. but there will be nowhere else viable to put the data, additionally 
we are saying its okay to compromise our principles when it suits us and puts 
us on a slippery road.  I do not think we should have or want a Fedora 
specific service. we could potentially use some new service not only for for 
fedorahosted but for pkgs git. having a good way for people to develop test 
and send patches to others seems like a huge win to me. I am sure we could 
probably work cross distro to have a universal solution with a big developer 
base.

Dennis

Dennis

[Paul W. Frields]

On Tue, Mar 10, 2015 at 09:26:59PM -0500, Dennis Gilmore wrote:
>  On Tuesday, March 10, 2015 05:56:58 PM Paul W. Frields wrote:
>  > On Tue, Mar 03, 2015 at 10:17:41PM -0600, Dennis Gilmore wrote:
>  > > -----BEGIN PGP SIGNED MESSAGE-----
>  > > Hash: SHA1
>  > > 
>  > > On Tue, 3 Mar 2015 13:30:26 -0700
>  > > 
>  > > Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  > > > On 3 March 2015 at 13:22, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  > > > > Greetings.
>  > > > > 
>  > > > > So, looking at fedorahosted, I thought I would start some discussion
>  > > > > about where we are and where we need to go short and longer term.
>  > > > > 
>  > > > > Right now hosted03/04 are rhel6 and still in puppet. Short term, I
>  > > > > would very much like to move them to ansible, and ideally to rhel7.
>  > > > > 
>  > > > > I looked into the trac situation upstream. We are currently using
>  > > > > 0.12.5 long term release on rhel6 (from epel6). There's a 0.12.6
>  > > > > thats out, but it looks like that might be the last release in the
>  > > > > 0.12 series (or there might be a 0.12.7, but thats likely to be
>  > > > > it). They are looking at doing releases yearly if they can manage,
>  > > > > so 1.2 would appear later this year, then 1.3, etc. It's not
> clear
>  > > > > how long 1.0 will be supported really. At least a year, but not
>  > > > > clear after that.
>  > > > > 
>  > > > > So, as I see it, our options are:
>  > > > > 
>  > > > > 1 Just move to ansible, leave on rhel6 for now until we decide
>  > > > > 
>  > > > >   something better.
>  > > > > 
>  > > > > 2 Move to ansible and rhel7, and build out trac-1.0 and plugins in
>  > > > > 
>  > > > >   epel7. This will take a bit longer since there's so many
> plugins,
>  > > > > 
>  > > > > but shouldn't really be that hard.
>  > > > > 
>  > > > > 3 Move to ansible and rhel7 and progit. I'm not sure if progit
> is
>  > > > > ready to replace trac though. I think it might need wiki features
>  > > > > and also more ticket handling stuff, since some of our projects use
>  > > > > trac ticketing heavily.
>  > > > > 
>  > > > > 4 a combo of 2 and 3 (ie, offer trac and progit both)
>  > > > > 
>  > > > > 5. a combo of 1 and 3 (ie, old trac projects stay on old hosted, we
>  > > > > move ones that want to progit, eventually we have a flag day and
>  > > > > move the rest).
>  > > > 
>  > > > 5 sounds like the most likely. There are a lot of work flows which
>  > > > groups are using with the current trac. If they didn't.. they would
>  > > > have probably moved over to github by now. Having the old boxes on
>  > > > ansible is probably faster by at least 18 months over getting people
>  > > > moved to the newer system.
>  > > 
>  > > I refuse to use github because I personally think its very bad for us as
>  > > a open and transparent community and project that prides itself on
>  > > making sure everyone can mimic what we do exactly to use something
>  > > closed and proprietary. For my own projects I think I would mostly be
>  > > okay with progit though something would be needed for ticketing for
>  > > releng, wiki space would be good for some projects but is not really
>  > > needed on all projects. some like mash only have a git repo on
>  > > fedorahosted, there is no associated trac. I think 4 or 5 would both be
>  > > viable.
>  > 
>  > [Sorry for catching up late to this thread.]
>  > 
>  > I'm not comfortable yet with the idea of taking on the service
>  > build-out that (3) represents above.  That's a lot of commitment for
>  > something I don't think we can call critical path.  Github may be a
>  > closed/paid service solution but it doesn't affect the public
>  > availability, transparency or forkability of any of our code.  And a
>  > long-term investment in chasing that solution as a Fedora-specific
>  > service to replace hosted is not necessarily the best use of our
>  > resources.
>  We can agree to disagree here. I think without a good viable open source 
>  option we will be locked into a closed proprietary platform. 
Define "locked"?  If we're able to take our data (and even issues) and
go elsewhere, where's the lock-in?

I would agree with you if this were about email, wiki, file storage,
or some other data type.  The DVCS factor clearly separates Github
from being an issue of lock-in or a slippery slope.  I don't know of
another type of data store where there's transparent, potentially
infinite mirroring to prevent lock-in.

>  if github jacks up the price or closes down, yes we still have our
>  clones and can put the data elsewhere. but there will be nowhere
>  else viable to put the data 
That's not how I read the above.  I don't believe Kevin suggested that
e.g. git.fedorahosted.org is dying or needs to shut down imminently,
or that Trac was no longer working.  I think the discussion is about
the long term roadmap for Trac, which is a living and breathing
(albeit slow moving AFAICT) upstream project we don't have to maintain
ourselves.

>  additionally we are saying its okay to compromise our principles
>  when it suits us and puts us on a slippery road.  I do not think we
>  should have or want a Fedora specific service. we could potentially
>  use some new service not only for for fedorahosted but for pkgs
>  git. 
Has someone already looked at Gitlab's hosted offering?  I understand
the reasons it's difficult to host our own instance, so I'm referring
to gitlab.com itself.

>  having a good way for people to develop test and send patches to
>  others seems like a huge win to me. I am sure we could probably work
>  cross distro to have a universal solution with a big developer base. 
Define "big"?  Working cross distro is a fine idea, but it only puts
us in front of the small percentage of developers working in distro
communities.  Most of them are elsewhere, and Github is one of the
largest communities of developers, as Matthew Miller has pointed out
in his FPL presentations.

None of this seems to address the resource problem.  Github gives us a
frictionless and transparent way to collaborate, it can't steal our
code, and the Fedora Engineering team doesn't have the cost of
maintaining it in the long run.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com

[Kevin Fenzi]

So, to recap... 

1. We will move fedorahosted to rhel7 soon (with trac, same as it is
now)

2. progit isn't a priority, as we have a ton of things to do and thats
a bit of a sidetrack from those. It however is an open source project
and people will continue to work on and improve it. We will continue to
ask for feedback and make it better and advertise it more. 

3. Down the road a while when progit is better we will decide when/if
it can replace the fedorahosted setup and/or if we can move things that
currently use github back to progit (either before or after any
fedorahosted migration). 

Does that all sound correct? 

kevin

[Dennis Gilmore]

On Wednesday, March 11, 2015 09:39:09 AM Kevin Fenzi wrote:
>  So, to recap...
>  
>  1. We will move fedorahosted to rhel7 soon (with trac, same as it is
>  now)
>  
>  2. progit isn't a priority, as we have a ton of things to do and thats
>  a bit of a sidetrack from those. It however is an open source project
>  and people will continue to work on and improve it. We will continue to
>  ask for feedback and make it better and advertise it more.
>  
>  3. Down the road a while when progit is better we will decide when/if
>  it can replace the fedorahosted setup and/or if we can move things that
>  currently use github back to progit (either before or after any
>  fedorahosted migration).
>  
>  Does that all sound correct? 
That sounds fine to me

Dennis